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FACILITATING THE NEGOTIATION OF STANDARDS FOR 
INTER-ENTERPRISE COLLABORATION BETWEEN TRADING PARTNERS 



TECHNICAL FIELD OF THE INVENTION 

This invention relates generally to electronic commerce, and more particularly 
to facilitating the negotiation of standards for inter-enterprise collaboration between 
trading partners. 
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BACKGROUND OF THE INVENTION 

For trading partners to collaborate, they must first agree on a set of standards 
for collaboration. One option for agreeing on a set of standards for collaboration is to 
utilize public standards. These are "one- size-fits-all," lowest common denominator 
5 standards that are unlikely to allow trading partners to differentiate themselves or 
adapt to the nuances of their businesses. Another option for agreeing on a set of 
standards for collaboration is to negotiate a private, differentiated standard. Once 
such a standard is negotiated (typically in extensible markup language (XML) form), 
significant time (e.g., months) may be required to enable the back-end collaboration 
10 software of the trading partners to adapt to the private standard. This can dramatically 
slow down efforts to establish and maintain collaborative relationships between the 
trading partners. 
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SUMMARY OF THE INVENTION 

The present invention may reduce or eliminate at least some disadvantages 
and problems associated with previous techniques for establishing standards for 
inter-enterprise collaboration. 
5 In accordance with a particular embodiment of the present invention, a system 

for facilitating negotiation of a standard for inter-enterprise collaboration between 
trading partners includes a set of one or more meta-model elements. Each 
meta-model element in the set is capable of being negotiated by two or more 
enterprises and incorporated into a negotiated meta-model that describes an agreement 

1 0 between the enterprises as to collaborations between the enterprises, each meta-model 
element in the set describing a portion of a potential standard for collaboration 
between enterprises. The system also includes a meta-model negotiation service 
operable to receive an indication that two or more enterprises wish to negotiate a 
standard for collaborations between the enterprises The meta-model negotiation 

15 service provides access to the set of meta-model elements and receives selections of 
one or more of the meta-model elements for negotiation and incorporation into a 
negotiated meta-model that describes an agreement between the enterprises as to 
collaborations between the enterprises. The meta-model negotiation service facilitates 
negotiation of the selected meta-model elements, incorporates the negotiated 

20 meta-model elements into the negotiated meta-model for collaborations between the 
enterprises, and communicates the negotiated meta-model to the enterprises to enable 
collaborations between the enterprises according to the standard for collaborations 
reflected in the negotiated meta-model. 

In accordance with another embodiment, collaboration software associated 

25 with an enterprise is embodied in computer-readable media and when executed is 
operable to receive a negotiated meta-model from a meta-model negotiation service. 
The negotiated meta-model incorporates multiple negotiated meta-model elements 
selected from a stored set of meta-model elements. Each meta-model element in the 
set is capable of being negotiated by two or more enterprises and describes a portion 

30 of a potential standard for collaboration between enterprises. The negotiated 
meta-model describes an agreement as to collaborations between the associated 
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enterprise and one or more other enterprises and is negotiated by the associated 
enterprise and the one or more other enterprises using the meta-model negotiation 
service. The collaboration software is operable to understand semantics of the 
negotiated meta-model substantially independent of modification of the collaboration 
5 software subsequent to negotiation of the meta-model and to substantially 
automatically collaborate with the one or more other enterprises according to the 
standard for collaborations reflected in the negotiated meta-model received at the 
collaboration software. 

In accordance with another embodiment, a negotiated meta-model enabling 

10 collaboration between two or more enterprises incorporates a number of negotiated 
meta-model elements selected fi-om a stored set of meta-model elements each capable 
of being negotiated by two or more enterprises. Each meta-model element in the set 
describes a portion of a potential standard for collaboration between enterprises. The 
negotiated meta-model describes an agreement as to collaborations between two or 

15 more enterprises and is negotiated by the two or more enterprises using a meta-model 
negotiation service associated with a network service provider. The negotiated 
meta-model includes semantics capable of being understood by collaboration software 
associated with each of the two or more enterprises substantially independent of any 
modification of the collaboration software subsequent to negotiation of the 

20 meta-model, such that the collaboration software of the two or more enterprises is 
operable to substantially automatically collaborate according to the standard for 
collaborations reflected in the negotiated meta-model. 

Certain embodiments of the present invention provide one or more technical 
advantages. For example, certain embodiments may provide a system for facilitating 

25 negotiation of a standard for inter-enterprise collaboration between trading partners 
using a trading partner agreement (TP A) that is substantially "machine- actionable," in 
that it may be understood and automatically acted upon by "adaptive" collaboration 
software of the trading partners substantially immediately upon its creation, without 
extensive modification of the collaboration software. This may dramatically reduce 

30 the time, expense, and needed resources associated with prior techniques in which 
developers, analysts, and other personnel associated with each trading partner were 
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required to independently understand a collaboration standard and then encode its 
semantics in their collaboration software before collaboration based on the standard 
could occur. Accordingly, significant time, expense, and resources associated with 
establishing inter-enterprise collaborations may be saved in certain embodiments. 
5 Certain embodiments of the invention may provide a meta-model negotiation 

service (MMNS) that allows trading partners to select certain meta-model elements 
from a template of possible meta-model elements, negotiate the selected meta-model 
elements according to particular needs, and have the negotiated meta-model elements 
incorporated into a complete negotiated meta-model for use in future collaborations 

10 between these trading partners. The MMNS may be a service provided by a network 
service provider. Use of the MMNS may allow trading partners to negotiate a private, 
differentiated meta-model, corresponding to a negotiated TP A, that provides value to 
the trading partners above and beyond what any existing "one size fits all," lowest 
common denominator standards may provide. Trading partners that have access to 

15 the MMNS and can therefore participate in negotiating a customized TPA with their 
trading partners may gain additional business as a resuh, particularly if those trading 
partners have adaptive collaboration software sufficient to read, understand, and act 
upon machine-actionable TP As received from MMNS. 

One or more other technical advantages may be readily apparent to one skilled 

20 in the art from the figures, descriptions and claims included herein. Moreover, while 
specific advantages have been enumerated above, various embodiments may include 
all, some or none of the enumerated advantages. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

For a more complete understanding of the particular embodiments of the 
invention and their advantages, reference is now made to the following descriptions, 
taken in conjunction with the accompanying drawings, in which: 
5 FIGURE 1 illustrates an example system for facilitating the negotiation of a 

standard for inter-enterprise collaboration between trading partners; 

FIGURES 2 through 5 illustrate example negotiation of a standard for 
inter-enterprise collaboration between trading partners; 

FIGURE 6 illustrates an example network service provider; and 
10 FIGURE 7 illustrates an example method for facihtating the negotiation of a 

standard for inter-enterprise collaboration between trading partners. 
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DESCRIPTION OF EXAMPLE EMBODIMENTS 

FIGURE 1 illustrates an example system 10 for facilitating the negotiation of a 
standard for inter-enterprise collaboration between trading partners. In general, 
according to the present invention, two or more enterprises 12 use an electronic 
5 marketplace or other network service provider 14 to negotiate a standard, which may 
be a private standard unique to these enterprises 12, for collaboration between the 
enterprises 12. The negotiated standard may be referred to where appropriate as a 
TPA and is preferably at least substantially "machine-actionable," such that 
collaboration software 16 of enterprises 12 can automatically execute a business 
10 process according to the negotiated standard substantially immediately upon creation 
of the standard, without requiring extensive modification of the collaboration software 
16. 

A meta-model is a description of a TPA that software, such as collaboration 
software 16, can read and understand. A meta-model may contain XML data or any 

15 other suitable type of software-readable data, depending on the implementation. In 
one embodiment, network service provider 14 supports an MMNS 18 to facilitate the 
negotiation of standards, in the form of TP As, for collaboration between enterprises 
12. In certain embodiments, the MMNS 18 may be referred to as a joint business 
planning network service (JBPNS). Although MMNS 18 is described, any suitable 

20 service may be supported at network service provider 14 to provide the features and 
operation described herein. Although MMNS 18 is described as being supported at 
network service provider 14, MMNS 18 may be supported using any appropriate 
computer system intermediate to enterprises 12. Furthermore, in certain embodiments 
MMNS 18 may operate wholly or partially at enterprises 12. As an example, each 

25 enterprise 12 may support suitable portions of MMNS 18, such that commimication 
between portions of MMNS 18 at different enterprises 12 may occur to negotiate 
standards for collaboration between enterprises 12. 

In contrast to previous techniques, as described above, TP As according to the 
present invention are preferably machine-actionable, such that collaboration software 

30 16 of enterprises 12 can understand a negotiated TPA and, substantially immediately 
upon its creation, begin collaborating according to the negotiated TPA with 
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collaboration software 16 of one or more other enterprises 12 that participated in 
negotiating the TP A. In one embodiment, this may be achieved by describing the 
entire meta-model of the standard reflected in the TPA in a form such that 
collaboration software 16 can understand its semantics and adapt to the standard 
5 accordingly. Previous techniques have required developers, analysts, and other 
personnel associated with enterprises 12 to understand a collaboration standard and 
then encode its semantics in collaboration software 16 of associated enterprises 12. 
This process may take significant time (e.g., months) and has been a major factor in 
the lack of adoption of private, differentiated collaboration standards. 

10 Enterprises 12 associated with network service provider 14 may be current or 

prospective trading partners and may include manufacturers, distributors, wholesalers, 
retailers, suppHers, end customers, or any other entities that participate in business 
processes or transactions. Enterprises 12 and network service provider 14 may each 
operate on one or more computer systems at one or more locations and may share data 

15 storage, communications, or other resources according to particular needs. These 
computer systems may include suitable input devices, output devices, mass storage 
media, processors, memory, or other components for receiving, processing, storing, 
and communicating information according to the operation of system 10. 

Network service provider 14 may be a business-to-business (B2B), 

20 business-to-consumer (B2C), or other network service provider that Hnks enterprises 
to each other. Enterprises 12 may interact with network service provider 14 
autonomously or according to suitable input from any number of associated users. 
Enterprises 12 may be coupled to network service provider 14 using one or more local 
area networks (LANs), metropolitan area networks (MANs), wide area networks 

25 (WANs), a global computer network such as the Internet, or any other wireline, 
optical, wireless, or other links. Enterprises 12 and network service provider 14 may 
conmiunicate with each other according to a hub-and-spoke, peer-to-peer, or other 
suitable architecture, hi one embodiment, system 10 is implemented using a 
hub-and-spoke architecture in which the spokes are appropriately integrated with 

30 enterprise systems of enterprises 12 and allow schedule-based data transfer between 
these enterprise systems and network service provider 14. 
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FIGURES 2 through 5 illustrate example negotiation of a standard for 
inter-enterprise collaboration between trading partners. In an initial state, as 
illustrated in FIGURE 2, collaboration software 16a associated with enterprise 12a 
collaborates with collaboration software 16b associated with enterprise 12b using a 
5 first meta-model ("Meta-Model-1"). Meta-Model-1 describes a TPA suitable for 
collaboration between collaboration software 16a and 16b and may be a standard 
TPA, a private TPA developed other than using MMNS 18, or a TPA negotiated 
according to the present invention using MMNS 18. In the illustrated embodiment, 
the collaboration software 16a also collaborates with collaboration software 16c using 

10 a second meta-model ("Meta-Model-2"), which like Meta-Model-1 may be any 
suitable meta-model. Similarly, collaboration software 16f collaborates with 
collaboration software 16d and 16e using appropriate third ("Meta-Model-3") and 
fourth ("Meta-Model-4") meta-models, respectively. Although particular 
collaborations and associated meta-models are illustrated and described for purposes 

1 5 of explanation, any suitable collaborations and meta-models may exist. 

In the example negotiation scenario being illustrated, enterprises 12a and 12f 
supporting collaboration software 16a and 16f, respectively, wish to collaborate with 
one another. Accordingly, as illustrated in FIGURE 3, enterprises 12a and 12f begin 
negotiating a standard to serve as the basis for collaboration between them. Through 

20 MMNS 18, enterprises 12 and 12f negotiate one or more meta-model elements that 
will be used to formulate a meta-model describing a negotiated TPA customized for 
their needs and suitable for their future collaboration. The negotiated meta-model 
elements and resulting meta-model may be distinctive to collaboration software 16a 
and 16f In one embodiment, enterprises 12a and 12f may select one or more 

25 meta-model elements from a set of possible meta-model elements commimicated to or 
otherwise made available to the enterprises 12a and 12f by MMNS 18. The set of 
possible meta-model elements may be provided in the form of a template accessible to 
enterprises 12. The set of possible meta-model elements is preferably constructed to 
include all meta-model elements that would be of interest to enterprises 12 within the 

30 marketplace environment of network service provider 14. However, at least in certain 
embodiments, MMNS 18 may also support the ability of enterprises 12 to define new 
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meta-model elements for use in combination with or instead of pre- validated 
meta-model elements in the predefined set of possible meta-model elements supported 
byMMNS 18. 

Each meta-model element typically deals with an associated set of potential 
5 terms, definitions, or standards that may collectively provide a complete description 
of a negotiated TP A. For example, meta-model elements supported by MMNS 18 
may include supply chain elements (also possibly referred to as dimensions) such as 
item (i.e. part number, stockkeeping unit (SKU), or other identifier), buffer (i.e. item 
at a location), site (i.e. location from which or to which shipping will take place), and 

10 resource (representing capacity). Once one or more of these or other supply chain 
elements have been negotiated and incorporated into a TP A, enterprises 12a and 12f 
can subsequentiy collaborate upon these elements to determine, for example, exactly 
which items will be involved in a business transaction, where the items are located, 
where they will be shipped from or shipped to, and what capacity will be needed to 

15 process the items. 

MMNS 18 may support one or more other types of meta-model elements that 
may be negotiated by enterprises 12 to serve as the basis for a negotiated TP A. For 
example, supported meta-model elements may include, in any suitable combination 
and without limitation: (1) role type elements that define who can participate in the 

20 collaboration (e.g., suppHers or buyers); (2) combinations of supply chain elements 
(also possibly referred to as dimensionality) on which collaboration may take place 
(e.g., item - site (ship from) - site (ship to), site (ship from ) - buffer, etc.); (3) access 
particular role types have to particular dimensionality; (4) collaborative transaction 
type (e.g., request for quote (RFQ)) relative to dimensionahty, such as the structure 

25 (e.g., hierarchical) and data elements of the transaction, a fiill state or other model 
describing the lifecycle of the transaction, the access that a role type has to the data 
elements of the transaction relative to the state of the transaction, the actions that a 
role type can execute on the transaction relative to the state of the transaction, and 
whether the transaction is the system of record or instead whether there is another 

30 system of record with which synchronization must occur; (5) shared computations, 
problems, alerts, and the like which both enterprises 12 can view (e.g., defined as 
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shared JAVA classes operating on the collaborative transaction which can execute on 
a standard JAVA Virtual Machine (JVM) at either enterprise 12; and (6) temporal 
horizon structure of the collaborative transaction (e.g., number of days, followed by 
number of weeks, followed by number of months). Although particular meta-model 
5 elements are described as examples, any appropriate meta-model elements may be 
supported at MMNS 18, selected by one or both enterprises 12 for negotiation, and 
negotiated by enterprises 12, according to particular needs. 

Once the appropriate meta-model elements have been negotiated, MMNS 18 
formulates a meta-model for the TPA including the negotiated meta-model elements. 

10 As illustrated in FIGURE 4, MMNS 18 communicates the negotiated meta-model 
("Meta-Model-5") to collaboration software 16a and 16f of enterprises 12a and 12f, 
respectively, in any suitable manner. Collaboration software 16a and 16f are capable 
of receiving and accepting the negotiated meta-model, as reflected in an associated 
TPA, understanding the semantics of the negotiated meta-model, and collaborating 

15 according to the negotiated meta-model. Collaboration may include executing one or 
more collaborative transactions according to the negotiated TPA. In the preferred 
embodiment, as described above, collaboration software 16a and 16f are capable of 
collaborating according to the negotiated TPA substantially immediately upon its 
creation, with little or no modification to collaboration software 16a and 16f This 

20 may provide an important technical advantage. 

In one embodiment, to enable collaboration software 16 to readily understand 
the semantics of any negotiated meta-model received from MMNS 18, collaboration 
software 16 is developed such that is understands the semantics of all possible 
meta-model elements supported by MMNS 18. As a result, the collaboration software 

25 16 understands and is capable of collaborating, substantially automatically, according 
to any negotiated meta-model that includes any combination of supported meta-model 
elements. Where collaboration software 16 has this capability, it may be referred to 
as being adaptive. As noted above, a negotiated TPA capable of being understood 
and then acted on substantially immediately and without significant modification of 

30 collaboration software 16 may be said to be machine-actionable. 
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In one example, enterprise 12a may be a buyer and enterprise 12f may be a 
supplier. Enterprises 12a and 12f have negotiated a meta-model (Meta-ModeI-5) 
based on item and site elements which has been formulated and communicated to 
collaboration software 16a and 16f by MMNS 18. In one example, enterprises 12a 
5 and 12f have negotiated a meta-model (Meta-Model-5) that will govern their future 
collaboration. They have negotiated that the purpose of the collaboration is to fulfill 
demand at a buyer site firom a particular supplier site for a particular item. Enterprises 
12a and 12f have also negotiated the structure of the collaborative transactions in 
terms of items, buyer sites, and supplier sites. The association between the negotiated 

10 collaborative transaction and the underlying supply chain elements such as item and 
site are in this example critical for the further negotiation of exceptions and events 
which are dependent on the state of the entire supply chain and other collaborative 
transactions in the supply chain. Enterprises 12a and 12f have further negotiated the 
nature that the demand signal will take, the nature that the supply response will take, 

15 and the protocol the adaptive collaboration software 16a and 16f will use to convey 
these signals. Furthermore, enterprises 12a and 12f have negotiated exception 
conditions that will manifest themselves when a particular party does not adhere to 
the negotiated protocol. Moreover, enterprises 12a and 12f have negotiated the 
logistics to physically ship the items. 

20 Collaboration software 16a and 16f may collaborate in accordance with the 

negotiated meta-model (Meta-Model-5) and determine that an item with a particular 
SKU is needed by enterprise 12a at a particular buyer site. This demand is then 
propagated to the supplier collaboration software 16f in accordance with the 
meta-model. The supplier's collaboration software 16f will then respond to this 

25 demand signal in accordance with the negotiated meta-model. If the response is 
within parameters, the buyer's collaboration software 16a will execute a purchase 
order in accordance with the meta-model. The supplier 12f will then ship the desired 
quantity of items on the desired date in accordance with the negotiated logistics 
model. At all times during the collaboration, the collaboration software 16a and 16f 

30 monitors this (and also other collaborative transactions) in relation to the supply chain 
to detect exception conditions and initiate events. Although a particular example is 



ATTORNEY'S DOCKET 
020431.1056 



PATENT APPLICATION 



13 

described, those skilled in the art will appreciate that the present invention is not 
limited to any particular collaboration scenario. 

FIGURE 6 illustrates an example network service provider 14 and interactions 
with various enterprises 12 in further detail. Network service provider 14 may 
5 include one or more firewalls 20 establishing a "DMZ" or other secure area 22 that 
separates enterprises 12 from certain processing and data storage resources of the 
network service provider 14. In one embodiment, DMZ 22 isolates a file transfer 
protocol (FTP) or other file server 24 that receives data files 26 from enterprise 
systems 28 associated with enterprises 12. File server 24 communicates data files 26 

10 to a database tier 30 of network service provider 14 for storage in database 32 as 
flatfiles or otherwise. Where network service provider 14 provides one or more 
hosted planning services, file server 24 may also receive planning output 34 from one 
or more plaiming engines 36 in an application tier 38 of network service provider 14. 
File server 24 may communicate planning output 34 to the enterprise systems 28 of 

15 enterprises 12 as appropriate. Planning engine 36 may interact with database 32 or, 
more preferably with respect to particular tasks, with an active data warehouse 
(ADW) 40 in which the information contained in data files 26 may be stored and 
updated. 

DMZ 22 also isolates one or more web servers 42, within a web tier 44 of 
20 network service provider 14, that communicate between manager 46 in apphcation 
tier 38 and one or more users 48 associated with the enterprises 12. For example, web 
server 42 may communicate with such users 48 using Hypertext Markup Language 
(HTML) pages or Extensible Markup Language (XML) documents contained within 
Secure Hypertext Transfer Protocol (S-HTTP) or other suitable requests. While 
25 file-based, web-based, and other communication techniques are described as 
examples, enterprises 12 may communicate with network service provider 14 in any 
appropriate manner without departing from the intended scope of the present 
invention. Where appropriate, reference to the actions of enterprises 12 is meant to 
encompass the actions of associated enterprise systems 28 and/or associated users 48. 
30 As described above, enterprises 12 may be entirely or at least substantially 
autonomous in certain embodiments. 
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Database 50 may store the meta-model elements that may be negotiated by 
enterprises 12 and information concerning the formulation of one or more negotiated 
meta-models based on individual negotiated meta-model elements. For example, as 
described above, database 50 may store a template containing all the possible 
5 meta-model elements which may be negotiated by enterprises 12 for inclusion in a 
final meta-model describing a particular negotiated TPA. Database 50 may also store 
one or more meta-models that have been used by enterprises 12 for previous 
transactions and can be modified, for example, on an element by element basis, to 
form new negotiated meta-models. Database 50 may store any suitable information 

10 relevant to the process of negotiating meta-model elements and formulating complete 
negotiated meta-models based on these elements. 

In one embodiment, manager 46 is responsible for managing the flow of data 
to, from, and within the network service provider 14 in connection with the 
negotiation of meta-model elements for a TPA, using the negotiated meta-model 

15 elements to formulate a complete meta-model for the TPA, and other activities 
described more fully above. Manager 46 may have access to ADW 40 if appropriate 
and may access the information stored in database 50 in connection with its 
operations. Although database 32, ADW 40, and database 50 are described as being 
separate, the present invention contemplates these components being wholly or 

20 partially integral to one another, according to particular needs. 

The components of network service provider 14 may be implemented using 
any suitable combination of software, firmware, hardware, or other suitable 
components. Software components of network service provider 14 may be 
implemented according to any suitable software methodologies. For example, 

25 plaiming engine 36 and manager 46 may be implemented using object-oriented 
software methodologies, and the meta-model elements, meta-models, and TP As may 
be represented using JAVA classes or other suitable object-oriented constructs. 

FIGURE 7 illustrates example method of facilitating negotiation of a standard 
for inter-enterprise collaboration between trading partners. The method begins at step 

30 100, where at least two enterprises 12 wishing to collaborate access MMNS 18 of 
network service provider 14. At least one of these enterprises 12 accesses the set of 
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possible meta-model elements supported by MMNS 18, in the form of a template or 
otherwise, at step 102. The current default meta-models of the two partners are also 
preferably made available at the time of negotiation. The resulting negotiated 
meta-model may be identical to one or other of the partner's meta-model, may be a 
5 hybrid of the current default meta-models, or may be completely unrelated to the 
current default meta-models. At least one of the enterprises 12 selects one or more 
meta-model elements from the set at step 104 and negotiates with the one or more 
other enterprises 12 as to the selected meta-model elements according to their 
particular needs at step 106. Enterprises 12 may negotiate meta-model elements 

10 individually in any suitable sequence, substantially simultaneously, or in any other 
suitable manner. At step 108, enterprises 12 and MMNS 18 cooperate to generate a 
final negotiated meta-model that incorporates the individual negotiated meta-model 
elements. The negotiated meta-model describes a TPA for future collaborations 
between the trading partners. Although the negotiated meta-model may be referred to 

15 as being complete or final, the present invention contemplates the meta-model being 
re-negotiated in response to specified triggers, periodically, or in any other suitable 
manner. Additionally, the meta-models are preferably versioned to facilitate 
re-negotiation. At step 110, MMNS 18 communicates the negotiated meta-model to 
collaboration software 16 of each enterprise 12. The collaboration software 16 of 

20 each enterprise 12 receives the negotiated meta-model at step 112. Where the TPA 
for the negotiated meta-model is machine-actionable and collaboration software 16 of 
each enterprise is adaptive, at step 114 the collaboration software 16 preferably reads 
the negotiated meta-model, understands its semantics, and can participate in 
collaborative business processes or transactions with other enterprise 12 according to 

25 the negotiated meta-model and its associated TPA. 

Although the present invention has been described in detail, various changes 
and modifications may be suggested to one skilled in the art. It is intended that the 
present invention encompass such changes and modifications as falling within the 
scope of the appended claims. 



